A step towards resolving #1510, but it does have a wide effect on a lot of components (e.g. search boxes, buttons, etc.) that would be failing (and causes them to pass).

As stated in #1510, we are currently failing WCAG 2.2 SC 1.4.11 (Level AA) which requires a minimum non-text colour ratio of 3:1 for user interface components and graphical objects. This was most notable for the search field and buttons.

This PR increases the lightness channels of the --border and --border-hover values for the light and dark colour schemes which in effect causes their contrast on the main background to just pass 3:1. The original issue did include the ratios of the borders and the inner surface (i.e. the background colour of the component itself). For buttons, I don’t think this is necessary. For text fields, this maybe necessary unless there are other visual elements within the border (e.g. our main search field has the leading ./).

Admittedly, just increasing the border contrast alone isn’t a great design decision. Adding other visual effects could help, but it would be a bit of a departure from the current design paradigm. There’s also the issue of pairing these border colours with different background colours—there could be failures.

Before	After
Contrast ratio: 1.257:1 (#262626 / #101010)	Contrast ratio: 3.167:1 (#636363 / #101010)
Contrast ratio: 1.574:1 (#CECECE / #FFFFFF)	Contrast ratio: 3.033:1 (#949494 / #FFFFFF)

Full page comparison of home and package views

Ignore other non-border-contrast visual differences. I’ve got screenshots of different builds. This is tedious work.

Before	After